By Andre Durand
Words have flywheels. Their inner mass carries old meaning into new contexts. We use them because they're handy and stable, like trusty old code. We need a tectonic shift in context to wake us up to the need for new words, or for new and more appropriate ports of the old ones.
Take "embedded."
Here on the brink of the next tectonic shift (trust me: we'll get to it), "embedded" has acquired a diminutive implication, owing mostly to the drift of press/daytrader attention from Linux to "appliances." The appliance fantasy is as old as Buck Rogers. From the Thirties to the Nineties, every few years the Science section of the Sunday paper would run a futuristic story of "smart" boxes and robots in the kitchen, fixing manufactured vittles for the for the happy family.
The brains of these things were all "embedded." Along with the brains of brake systems, PDAs, mobile phones, pagers, hearing aids, and movie viewers on airplanes. Little things.
But embedded applications were never just about small-scale stuff.
Since we're talking "embedded" here, let's start by getting our definition straight. An embedded device is anything that isn't a PC — by which we mean a box running a familiar operating system, whether its a client, a server or both. Our familiar operating systems are made to do pretty much anything and everything. They are general in purpose. By contrast, an embedded operating system is special in purpose. Its scope is limited entirely by the singular purposes to which it is put. It has no more than the required device drivers, services and APIs.
To embedded operation, size isn't the issue. Purpose is. A massive telephone switching system may have a specialty no larger in operational scope than a pager. Both are special. Neither are general.
For all of computing's history, the difference between "special" and "general" operating systems was not just a matter of scope. It was a massive difference in kind. Nearly every attempts to leverage one to the other failed. I watched it happen at Novell, whose NOS — Network Operating System — the familiar NetWare, grew under my strategic direction to become the nearly ubiquitous way to deploy file and print services.. Later Novell tried to take that special purpose OS and make it general. MIcrosoft, which had failed with MS-NET and a bunch of other strategies, finally succeeded with NT, which added NetWare-compatible file and print services to the OS's roster of other talents. But NT didn't get more special. It only got more general by annexing Novell's legacy services. Novell's dream of making NetWare an alternative to NT (and every other networked OS) was always wet.
The same problem doomed Apple and Microsoft, going in the other direction. The first PDA (an acronym coined by Apple CEO John Sculley) was the Newton, which was born with an entirely new OS that still suffered from the general purpose biases of its creator, a do-it-all-on-the-desktop PC company. The first Newton was born too big and too broad. It did too much. Today Windows CE has the same problem, after no less than half a decade of trying to shrink itself, CE doesn't cut it. Worst of all, only Microsoft can whittle it down, and Bill Gates would rather geld himself than make a truly compact operating system — especially one as famously free and open as Linux.
The traditional embedded OS companies — Wind River, Mentor Graphics — have always treated the embedded world as a large and comfy niche. Also known as the Real Time world, it was a place where conversation revolved around the virtues of real time operations, and arcane hardware/software combinations that delivered the best performance.
Until just this last year. Suddenly a bunch of old timers in the embedded world have either adopted Linux or been adopted by Linux companies. James Ready, the embedded pioneer who founded Ready Systems a few years back, now runs MontaVista <www.mvista.com>, which launched HardHat Linux last year. RedHat acquired Cygnus last year, then WireSpeed in June of this year. Last summer Caldera, an early Linux distribution leader, spun off Lineo as an embedded Linux company. Both Lineo and MontaVista have substantial venture capital backing, and are themselves in aggressive acquisition mode. The traditional embedded publications and events are suddenly abuzz with Linux coverage.
Not least in importance is the fact that Linus Torvalds himself went to work for Transmeta four years ago, and has steadily advocated an increasingly embedded direction for Linux kernel development.
What makes Linux so special here? Embedded Linux companies and customers alike talk about the vast reservoir of development talent already working with the OS. But the critical virtue is this: Linux is the first and only general purpose operating system that easily adapts to special purpose applications — that's easily embedded. Others have tried.
any size, from small appliances to telephone switches. What they do is provide the tools and the basic system for a vendor to build a special purpose version of linux for whatever platforem they want to put it on. They'll customize it as another set of services for the embedded product vendors. Their revenue comes from building device drivers (see email) and the tools to develop and test and debug the embedded implementation.
The Net took decades to grow up, then exploded in the few short years it took to put e- in front of every business and .com after every name.
It's about to explode again, by approximately the volume of every potentially connected device that isn't already running Linux. We're not just talking appliance clichés like toasters, refrigerators and cell phones. We're talking industrial controls, lawn sprinklers, car radios, phone system switches, elevators, you name it.
Three forces will combine to create a new universe: Embedded Linux, XML and Instant Messaging. What makes this un
Jabber is infrastructure for all embedded applications, and the way they communicate to the Web, with apps on the PC connected through the net, and for PCs talking to each other.
Make this thin jabber client part of your SDK,
Need to show an application's ability to send and receive messages by means of structured XML documents.
You send instructionsn to a device by structured XML. that's it. Makes total sense. We're packetizing messages in XML documents.
by doing that way, versus any other proprietary way, you yhave now exposed by the messages which are being sent from the device to all of the infrastructure on the internet which is capable of parsing and acting on xml. Thinik about the new XML databases that are designed to parse that xml and store it in a database.All of the other int4erfaces in which xml will be the preferred way to receive information, and the preferred way in which they're going to send it. So now you've conformed these devices to this incoming xml standard on the internet.
if a device sends an instruction somewhere and does just some random programmatic proprietery way, nothing on the internet can leverage its inherent message. Whereas if you do it with xml and embed it in that standard, all the other tools and application layers that are able to receive and send those messages now can speak to it.'
The result is an interoperability framework. It is instigated by instant messaging, but it applies in much broader ways. It's a generational leap.
If the device world, using embedded Linux — or any operating system, for that matter — employs an XML methodology of talking to and from devices, they are interoperable with everything now being built on the internet.
The concept that, if the device world on embedded linux employs a methodlollogy of talking both to and from the devices via xml documents, they are interoperable with everything that's now being built on the internet.
Jabber itself is an SDK for connected messaging to the device world.
By reconceiving a transported document as a message changes the definition of a message.
The xml format becomes a standard envelope that the Internet understands. The contents of that envelope are infinitely flexible. By building a framework in XML for your messaging architecture, what you do is defined a standard way to send messages with an infinitely variable dynamic protocol. You can change what you put in there forever, and everybodfy can understand it because you have the overall common framework.
In the plate tectonics of the industrial world, this is a whole new continent, starting to push up out of the seas. It's not a large and ancient continent like PCs. Messaging in the PC world has all kinds of conceptual entailments. But in the device world, it's brand new.
THE XML paradigm
With Jabber a messege is embedded in a structured XML document. You can send instructions to a device by XML. You sort of packetize the message inside the XML document. By doing it that way, rather than in some proprietary way, you have now exposed the messages sent from the device to all of the infrastructure on the Internet that is capable of parsing XML and acting on it.
sidebar vision of the use of jabber
at the heart it's a ubiquitous XML router. It might atg some future require streamlining Jabber both at a client and a server level, the way in which Linux has been streamlined for embedded Linux.
The thought process is, how will devices send status and receive instructions? What is the methodology for that? If the way in which they send and and receive information is via XML documents, that puts them on par with the way in which structured content will be transfered on the internet.
This will make it easy for a browser to interface directly with a device. And it will allow all the other informaiton in databases and structures and ASP servieces that are also inputing and outputting XML as the standard way to deal with othere ASP services, busienss iand things... it will put them all on par with those services as well. So it take a vision that extgencs not necessarily to what's the most efficient way for a device to talk to a device, butr what's an easy way for a device to talk to a devidce that's compatable with the way that information can be intervaced through a PC and a browser and all the other things that are XML aware on the internet.
It may not even matter how devices talk to devices today. I know from conversations with Embedded Linux companies that they are seeing a large numbers of embedded linux applications and devices that are using embedded linux come homing in on that same concept for the way devices send and receive messages.
I think the process will accellerate. I see an XML-based messaging SDK for embedded linux -- so the developer isn't just starting with raw Linux . They can pick up a jabber server, install it somewhere, then pick up the thin jabber embedded Linux client, then have a nice clean SDK to that client, for passing XML back and forth. That XML can go to that Jabber server and back to another device; or can go to that Jabber server and route its way to a client that's running on a PC, or route its way to a Web browser. Any one of those combinations.
A generation of embedded Linux/Jabber applications is inevitable. As a matter of fact, I think that the primiary application for this will be wireless. That's because I see Jabber as infrastructure for all these applications and the way they'll communicate with the Web. It's all the infrastructure you'll need. You put this little thin Jabber client as part of your embedded Linux SDK and you'll start seeing demonstraions of apps sending and receiving messages via structured XML documents, and to act on them.
This is a wake-up call to the fact that embedded Linux opens an avenue for countless developers to start imagining what can be done beyond applications on computers. That avenue leads to everything else. It's the avenue Linus has been pointing down ever since he led the way by joining Transmeta.
There are immediate practical concerns that Linux addresses as well, such as the ability to cram it into an eight meg Flash memory chip with room to spare, which isn't possible with Windows CE. Suddenly hackability goes everywhere. There are embedded operating systems, of course, from companies like Wind River. But Linux has advantages there, too. While Windows CE comes from the desktop, hauling along a small suite of downsized desktop applications that are utterly irrelevant to 99.9% of the embedded world, Wind River comes strictly from that embedded world, which has excluded 99.9% of the world's developers. Linux bridges both worlds. So does instant messaging.
The next big step will be wireless, of course, because it removes the last of the physical hurdles to logical connections between everything.
An example. You've got X10, which controls powered devices in the home. X10 has an open API. so the Jabber folks can write an agent gateway to X10. We've got a computer running X10 server running to a light on my desk. On my PC I've got a jabber client with five buddies, and a group called "My Home." Below my home I have "Light Switch/Living Room." I just sit there and turn my light on and off with a task bar on my desktop. I just send an XML message from my PC client (which doesn't have to be Jabber, but might as well be) to a Jabber server, which translates it into a native X10 message that says "power up that switch." So we're talking about XML and Jabber's ability to bridge protocols, which it was originally designed to do.
Extrapolate that, and you've got a device driving framework for all of reality. Because it is now quite simple for you, or a contractor you hire, to program your home. You can operate, and receive notification about, all the home electronic conveniences you already have: your security system, your lighting, your sprinklers. YOu can also program the devices to tell you if they're on, functioning and ready to receive instructions. So the concept of presence applies in more than one direction. So the two way conversation that includes presence is Jabber infrastructure on a common XML framework.
The advantage of XML is that it's text, plus a structured dynamic framework for what you put in that text. So I can add an XML tag to control the light switch. A feature of XML is the DTD — the Document Type Definition. With DTDs, you get to specify what type of document this is, inside the document. This allows an infinite variety of tags. The real estate industry, for example, could create a tag called "price." Everybody in the real estate trade can know what that tag means, and program their applications accordingly. The fact that you can build a DTD, publish it, and make it knowable, makes this framework especially flexible. You can create repositories of DTDs, or your XML application will specify whatever DTDs it requires. But the information defines itself. This is a hard concept to understand in a world that has nown nothing but rules sinde ehe befnning. When devices do this, it's very natural and simple. When you broaden hyour scope to all devices, computers included, talking to each other on their own terms, you begin to get the excitement we're starting to feel here.
You're developing an app that runs on embedded linux, and actionable information needs to be sent to somebody or something with a need to know. So do it in XML documents.
Already more and more applications are being built to understand and take advantage of the XML framework. But it really opens up for embedded devices when we add instant messaging infrastructure like Jabber, which is nothing more than a framework that combines presence with XML routing, plus a whole suite of robust client-side libraries on multiple OSes including embedded Linux. This will open up application development that takes advantages of this whole new infrastructure.
For Linux developers, it opens the world in two directions: 1) linux now operates in, and drives, virtually any kind of device; and 2) protocol-free and dynamic relationships can be created and improved on a constant basis. That's a pretty exciting prospect.
Thinking a bit out loud here, let me try to lay down some basic thoughts
which can be used as the incubus for some graphics for the Linux Journal
article. This is all for discussion purposes, I'm hoping that by writing
this down and conversing about it, I'll be able to better distill this into
the graphics we're looking for.
XML as a standards based framework for a dynamic protocol
=========================================================
Historically, most protocols did not distinguish or separate out 'framework'
from 'content'. Meaning, the protocol was both a framework for communication
tied together with the content. In this scenario, the protocol became
static, in that, changing either meant changing the protocol itself.
The concept we're playing with is the concept that the protocol that we're
talking about, one based on XML, is not only standards based (having a whole
slew of possibilities thereof), but, it is also inherently dynamic. As, XML
itself, as a protocol to define data, is inherently dynamic.
The key to Jabber's use of XML, and the key to XML itself, is that it
inherently accommodates change. Thus, the framework is separated from the
content(DTD's and specific XML tags). In this scenario, the 'framework'
(XML) stays standards based, but, the content (XML tags) can change at will,
and can be application specific, conforming to no published DTD's, or
completely conforming to industry standard DTD's, thus allowing it to
operate and exchange data with other services, databases and applications in
defined and known ways.
General Notes
=============
Doc, with respect to your article, I think it is important to note that
while Jabber can be described generically as an XML router, that, it is
specially tuned to 'routing in near real-time'. Meaning, email *could* route
XML documents, just as easily as Jabber. But, when you combine the need for
presence etc., then, Jabber is unique from some of the existing transport
protocols. I'd be concerned that we lay out this grand schema for 'Jabber as
an XML router' in a generic sense, without enough regard for the fact that
I'm sure other transport protocols could do the same thing, in both direct
and round-about ways.
Jabber stands unique at the following intersection of capabilities.
1. open-source movement
meets
2. distributed server architecture
meets
3. built in inherent use of XML as a dynamic framework for structured
content and message format
meets
4. built in presence or 'state' detection, awareness and broadcasting across
a distributed network
Ok, with that in mind, here are 3 graphics....